Every controls engineer has sat through the vendor slide with the padlock icon and the phrase “built on Secure by Design principles.” Fewer have watched what happens when that same vendor ships a firmware update eighteen months later with a known CVE still unpatched, no advisory, and a support contract that says nothing about disclosure timelines. That gap — between the marketing commitment and the purchase order — is where most manufacturing plants currently live, and it’s the reason ransomware keeps finding a way onto OT networks through the equipment that was supposed to be the trusted part of the stack.
CISA’s Secure by Design pledge program has done something genuinely useful over the past couple of years: it got major automation and industrial software vendors to sign their names to specific commitments — reducing default passwords, publishing vulnerability disclosure policies, shipping software bills of materials, cutting classes of vulnerabilities like SQL injection and path traversal out of new products. That’s real progress. But a pledge is a public statement of intent, not a warranty. It creates no obligation to any individual customer, no remedy if a vendor falls short, and no timeline you can enforce. If you want those commitments to mean something for your plant specifically, they have to show up in the contract you sign, not just the CISA press release you read.
Why “we follow Secure by Design” isn’t a clause
Procurement and legal teams are now getting pressure from plant IT and OT security leads to “put the CISA stuff in the contract,” and that instruction, as given, is close to meaningless. Secure by Design is a set of principles and voluntary goals. IEC 62443 is a family of standards with multiple parts, multiple security levels, and role-specific requirements for component suppliers, system integrators, and asset owners. Neither one is a drop-in legal clause. A vendor can truthfully say they align with both while still leaving you with no enforceable right to a patch, a disclosure, or a breach notice within any timeframe you can plan around.
The translation work — from standard/pledge to obligation, remedy, and deadline — is exactly what most capital equipment RFPs skip. Engineering writes the technical spec. Legal writes indemnification and warranty boilerplate. Nobody owns the section that says what the vendor has to do when a vulnerability is found in the HMI six months after commissioning.
What actually holds up versus what’s decorative
Not all security language in a vendor contract carries equal weight. Some of it is enforceable. A lot of it is checkbox language that sounds protective and does nothing.
Language that actually holds vendors accountable tends to share three traits: a defined trigger, a specific timeframe, and a stated consequence. Language that doesn’t have those three things is marketing, however good it sounds.
- Patch and remediation SLAs. “Vendor will provide timely security updates” is decorative. “Vendor will issue a patch or documented compensating control for critical vulnerabilities (CVSS 9.0+) within a defined number of days of public disclosure or vendor discovery, whichever is earlier, and will notify Customer’s designated security contact within a defined number of business days of the vulnerability’s existence” is enforceable — because it has a trigger, a clock, and a named recipient.
- SBOM delivery cadence. A one-time SBOM at commissioning is nearly worthless in a system you’ll run for a decade or more. The clause that matters requires an updated SBOM on every firmware or software release, in a machine-readable format (CycloneDX or SPDX), delivered to a specific address or portal — not “available upon request,” which in practice means available never.
- Vulnerability disclosure and coordinated disclosure participation. Require that the vendor maintain a documented vulnerability disclosure process consistent with ISO/IEC 29147 and 30111, and that they’ll notify you directly — not just via a public advisory you have to monitor for — when a vulnerability affecting your specific installed product is confirmed.
- Breach notification. This is the one legal teams already know how to write from the IT world, but OT contracts routinely omit it or leave it so vague (“without undue delay”) that it’s unenforceable. Put a number on it: notification within a defined number of hours or days of the vendor becoming aware that its product, remote access tooling, or cloud service was involved in an incident affecting your environment.
- End-of-life and support-window commitments. Secure by Design is meaningless on a platform the vendor stops patching five years into a twenty-year asset life. Require published end-of-support dates at time of sale and advance notice — a defined number of months — before support or patching ends.
What doesn’t hold up: references to “industry best practices,” “reasonable efforts,” “commercially reasonable security measures,” or simply citing CISA’s Secure by Design pledge or IEC 62443 by name without specifying which security level, which requirements, and what happens if the vendor doesn’t meet them. Standards citations without a mapped obligation are there to make the contract look thorough during audit, not to protect you during an incident.
A model addendum structure you can actually adapt
Rather than trying to rewrite your legal team’s master purchase agreement, most plants get further faster by attaching a security addendum or exhibit to the capital equipment RFP and purchase order — a document engineering and IT can draft jointly and hand to legal for enforceability review. A workable structure:
- Scope definition. Name the specific product, firmware, and any embedded third-party components covered.
- SBOM delivery. Format, cadence, and delivery mechanism, tied to every release, not just initial delivery.
- Vulnerability disclosure and notification. Defined severity tiers (map to CVSS), defined notification windows per tier, named contacts on both sides.
- Patch/remediation commitments. Timeframes by severity, and an explicit compensating-control option with documentation requirements for cases where a patch isn’t immediately possible on a validated production system.
- Remote access and authentication baseline. No default or shared credentials at delivery, MFA support for any vendor remote access, logging requirements.
- Breach/incident notification. Defined hours, defined content (what’s known, what’s affected, what’s being done), escalation path.
- End-of-life notice. Advance notice period before support or patch availability ends.
- Audit and evidence rights. Right to request evidence of the above — not full source code or a full security audit, which most vendors will and reasonably can refuse, but attestations, SBOMs, and disclosure records.
- Remedy. What happens on failure — credit, extended support at no charge, right to terminate for repeated material breach. Without this section, everything above is aspirational.
Where plants get this wrong
The most common failure isn’t missing language — it’s language with no owner. A plant negotiates a strong addendum, signs the PO, and then nobody on staff tracks whether the vendor actually delivers the quarterly SBOM or hits the disclosure window, because that job sits between OT engineering, IT security, and procurement and nobody claimed it. Contract language you don’t operationalize is functionally the same as no contract language. If you’re going to negotiate these clauses, assign someone — plant IT security lead is the usual candidate — to actually receive, log, and act on what the vendor sends.
The second failure is treating this as a one-time RFP exercise instead of a renewal cycle discipline. Secure by Design commitments, vendor security postures, and CVE disclosure practices all shift over the life of a piece of capital equipment that may run for fifteen or twenty years. Build a review trigger into every major service renewal and firmware update cycle, not just the original purchase.
None of this requires waiting on your legal department to become OT security experts overnight, and it doesn’t require boiling the ocean on your next RFP. Pick the handful of clauses above with real triggers and real timeframes, get them into the addendum, and hold the vendor to them starting with the next contract that crosses your desk. That’s the difference between citing Secure by Design and actually buying it.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
